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Abstract 


Recently,  many  Low  Earth  Orbit  (LEO)  satellite  systems  have  been  proposed  for  the 
purpose  of  global  communication  and  one  of  those  systems  is  planned  to  start  the 
commercial  service  in  1998.  These  LEO  satellite  systems  are  providing  most  of  current 
communication  services  (voice,  fax,  data,  paging,  and  even  real  time  video  service)  without 
any  limitation  on  place  and  time.  However,  little  is  published  about  their  detail  system 
methodology  on  user  tracking  and  managing  schemes.  This  thesis  presents  two  user 
location  tracking  algorithms  in  a  LEO  environment.  One  ( Gateway  Approach)  is  the  most 
likely  approach  under  present  system  proposals,  while  the  other  ( Satellite  Approach)  requires 
more  risk  in  implementing  the  proposed  scheme.  These  two  approaches  are  compared  via 
computer  simulation  in  an  Iridium-like  satellite  network  system  environment.  Comparative 
measures  of  call  setup  delay  and  number  of  hops  needed  to  establish  initial  call  request  are 
examined,  and  minimum  requirements  for  the  Satellite  Approach  are  discussed.  It  is 
concluded  that  the  Satellite  Approach  performs  better  than  the  Gateway  Approach  when  the 
memory  space  and  computational  ability  of  each  satellite  can  satisfy  the  minimum  conditions 
discussed  in  this  paper.  Also,  the  Satellite  Approach  experienced  well  balanced  message 
distribution  than  the  Gateway  Approach.  Moreover,  as  far  as  system  survivability  and  service 
continuity,  the  Satellite  Approach  showed  more  advantageous  factors  than  the  Gateway 
Approach. 
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1.  INTRODUCTION 


1. 1  Background 

For  decades,  geostationary  satellite  systems  have  been  in  the  main  stream  of  the  satellite 
communications  industry,  because  of  reliable  communications  with  ease  of  ground  station 
tracking  due  to  their  "fixture  in  space"  characteristics.  However,  major  drawbacks  to 
geostationary  systems  are  their  size,  energy  requirements,  and  the  one-way  signal 
propagation  times  of  approximately  120  milliseconds. 

In  order  to  reduce  the  size,  energy  requirements,  and  propagation  delay  associated  with 
geostationary  systems,  researchers  have  begun  to  reexamine  the  possibilities  of  placing 
multiple  cooperating  satellites  into  low  earth  orbital  (LEO)  planes.  Against  having  the 
advantages  of  reductions  in  size,  energy  requirements,  and  signal  propagation  times,  LEO 
satellite  systems  have  disadvantage  of  the  increased  number  of  satellites  required  to  cover 
whole  globe. 

1.2  Problem 

Like  cellular  network  system  environment,  LEO  satellite  network  systems  need  to 
maintain  user  location  information  in  order  to  provide  prompt  connection  between  mobile 
users.  This  leads  the  need  of  effective  user  location  update  mechanism  and  delay-free 
retrieving  algorithms  for  LEO  satellite  network  systems.  However,  little  is  known  about  the 
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algorithms  related  with  this  problem  and  no  official  technical  document  is  published  yet, 
even  though  one  of  the  major  LEO  satellite  network  systems  is  planned  to  start  commercial 
services  in  1998. 

This  thesis  examines  user  location  update  (ULU)  and  user  location  determination  (ULD) 
algorithms  in  the  cellular  network  system.  From  this  examination,  two  user  ULU  and  ULD 
algorithms  for  LEO  satellite  network  system  environment  are  modeled  and  analyzed. 

1.3  Scope 

This  research  suggests  two  ULU  and  ULD  algorithms  and  compares  the  performance  of 
those  two  algorithms  in  terms  of  call  setup  delay,  message  distribution,  and  memory 
requirement.  No  devices  are  implemented  in  this  thesis. 

1.4  Approach 

First,  using  current  standard  of  ULU  and  ULD  algorithms  in  cellular  network  system, 
two  new  ULU  and  ULD  algorithms  for  LEO  satellite  network  were  derived.  Then,  using 
BoNES  Designer  and  SatLab  simulation  tools  published  by  Cadence  Software,  two  ULU 
and  ULD  algorithms  were  simulated.  Because  of  the  fact  that  only  the  Iridium  satellite 
network  system  has  the  inter-satellite  link  (ISL)  function,  this  system  is  used  for  examination 
via  simulation. 

1.5  Summary 

This  thesis  is  organized  as  follows.  Chapter  2  gives  a  brief  survey  of  previously 
proposed  user  location  tracking  schemes  in  cellular  network  systems.  In  Chapter  3,  two  user 


2 


location  tracking  algorithms  are  proposed  for  satellite  network  systems.  Chapter  4  presents 
the  performance  analysis  of  the  two  different  algorithm  and  the  conclusion  is  given  in 
Chapter  5. 
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2.  PRIOR  WORK 


2. 1  Introduction 

Since  the  first  satellite  launch,  there  has  been  an  increase  in  use  and  diversity  of 
application  (i.e.  mobile  communication,  TV  broadcasting,  weather  reporting,  Global 
Positioning  Service,  military  reconnaissance)  for  these  machines.  Now,  more  than  two 
thousands  satellites  currently  operate  in  space  and  more  than  seventeen  hundreds  satellites 
will  be  launched  within  ten  years  [Wha97].  Most  early  satellites  were  fixed  in  a  geostationary 
orbit  (GEO  satellites)  and  provided  continuous  communication  service  to  a  small  number  of 
users  at  high  data  rates  in  a  given  area.  The  high  altitude  (about  35,785  km)  of  the 
geostationary  orbit,  however,  results  in  a  one-way  single-hop  (uplink  and  downlink) 
propagation  time  of  at  least  0.25  seconds. 

The  only  way  to  overcome  the  0.25  seconds  propagation  delay  associated  with  GEO 
satellites  was  to  put  satellites  in  orbits  of  lower  altitude.  In  doing  so,  the  delay  can  be 
reduced  to  approximately  0.005  seconds  for  an  up/ downlink  transmission  for  a  satellite  at  an 
altitude  of  780  km.  A  trade-off  exists  in  using  low-earth  orbit  satellite  systems  (LEO 
satellites)  compared  to  GEO  satellites.  LEO  satellites  must  maintain  high  orbital  velocities 
(approximately  17,000  mph)  in  order  to  keep  their  altitude.  And  also  the  region  which  can 
be  covered  by  one  LEO  satellite  is  relatively  small.  Thus,  in  order  to  cover  on  a  larger  area 
without  any  loss  of  coverage,  more  satellites  are  needed. 
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2.2  Planned  LEO  satellite  network  systems 

There  are  three  types  of  LEOs:  little-LEOs,  big-LEOs,  and  broadband-LEOs  [Cor97]. 
Litde-LEOs  operate  at  frequencies  below  1  GHz.  Orbital  Sciences  Corporation's 
OrbComm,  STARSYS  Incorporation’s  STARNET,  Volunteers  in  Technical  Assistance’s 
VITASET  are  examples  [WuM94]  of  little  LEOs.  They  are  designed  to  provide  full-time, 
global,  two-way  digital  communications  services:  messaging,  emergency  alerts,  position 
determination,  and  remote  data  collection.  “Little”  means  that  the  satellites  are  small  and 
light  compare  to  big-LEOs  and  also  scheduled  to  provide  only  low  bit  rates  (of  the  order  of 
1  kb/s). 

Big-LEOs  operate  at  frequencies  between  1  and  3  GHz.  They  will  provide  a  full  range 
of  mobile  satellite  services:  voice,  data,  fax,  paging  and  RDSS.  Motorola's  Iridium,  Loral  and 
Qualcomm's  Globalstar,  and  TRW's  Odyssey  are  members  of  the  big-LEO  family.  The 
Iridium  system  comprises  66  satellites  in  6  near  polar  orbits  at  an  altitude  of  785  km. 
Iridium  will  provide  full  services  with  global  coverage  [WuM94].  It  is  also  the  only  big-LEO 
system  attempting  to  use  satellite-to-satellite  crosslinks  designed  to  make  the  network  system 
be  more  flexible  in  propagating  messages.  Figure  1  shows  the  constellation  of  Iridium 
satellite  system. 

Globalstar,  which  is  being  developed  by  Loral  Aerospace  Corporation  and  Qualcomm, 
consists  of  48  LEO  satellites  orbiting  at  an  altitude  of  1,401  km.  The  satellites  are  equally 
divided  into  eight  orbital  planes.  The  system  will  use  traditional  bent-pipe  transponders 
instead  of  on-board  processing  (used  in  Iridium  system)  and  is  intended  to  work  with  the 
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Figure  1  Constellation  of  Iridium  system. 

existing  public  switched  telephone  network  (PSTN).  Calls  are  relayed  through  the  satellite 
only  when  access  cannot  be  made  via  the  terrestrial  network.  The  existing  PSTN  will  be 
accessed  via  gateways  and  will  be  used  for  long-distance  connections  including  transoceanic 
calls  [WuM94],  Figure  2  shows  the  constellation  of  Globalstar  satellite  system. 

The  Teledesic  satellite  system  is  by  far  the  newest  and  the  most  ambitious  of  the 
proposed  systems.  It  is  consists  of  840  satellites.  The  satellites  reside  in  21  planes  in  a  sun- 


Figure  2  Constellation  of  Globalstar  system. 
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synchronous,  inclined  circular  low  earth  orbit.  Teledesic  aims  at  providing  high  data  rate 
(broadband)  fixed  and  mobile  services,  continuous  global  coverage,  fiber-like  delay  and  bit 
error  rates  less  than  lO10.  Thus,  rather  than  targeting  voice  and  supporting  low  bit  rate  data 
as  the  big-LEOs  do,  Teledesic  focuses  on  providing  wireless  broadband  services  with  a 
fiber-like  quality,  focusing  on  data  and  supporting  voice.  Figure  3  shows  the  constellation  of 
Teledesic  satellite  system. 


Figure  3  Constellation  of  Teledesic  system 


2.3  Problems  associated  with  LEO  satellite  systems 

As  mentioned  earlier,  satellites  in  LEO  are  moving  at  speeds  of  15,000  to  17,000  km  per 

hour.  This  means  that  the  inter-satellite  network  topology  is  rapidly  changing.  Also,  the 

satellite  itself  is  not  as  powerful  as  the  terrestrial  network  nodes  because  of  the  limited  space 

and  energy  capability.  Under  these  circumstances,  a  database  is  needed  by  a  user  location 

update  (ULU)  policy  that  minimizes  the  computational  overhead  and  cost.  An  user  location 

determination  (ULD)  algorithm  is  also  needed  to  use  that  database.  In  this  thesis,  two  types 

of  user  location  determination  algorithms  are  proposed  along  with  a  user  location  update 
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algorithm  for  the  LEO  satellite  network  environment.  The  performance  of  the  two 
algorithms  are  then  compared. 

2.4  User  Location  Management  Algorithms  in  WirelessPCS  Networks 

In  most  wireless  personal  communication  services  (PCSs),  the  most  recent  location  of 

the  user  is  needed  to  efficiendy  communicate.  For  mobile  networks,  user  location 
determination  may  be  inexact.  The  source  determines  the  most  likely  location  of  the 
destination  user.  Then  the  source  terminal  tries  to  find  the  destination  from  this  location.  If 
the  destination  terminal  is  still  in  that  location,  end-to-end  communication  can  begin.  But  if 
the  user  is  not  there,  the  source  terminal  has  to  propagate  the  searching  signal  to  adjacent 
locations  until  it  finds  the  destination.  Predicting  expected  user  location  usually  depends  on 
the  history  of  calls  and  moving  pattern  of  the  terminals  [AkH95].  Terrestrial  cellular  systems 
use  these  pieces  of  information  for  assistance  in  finding  mobile  users. 

The  authors  of  [BaK93]  introduced  a  mobile  terminal  location  update  scheme  under  a 
cellular  architecture  where  base  stations  are  interconnected  by  wireline  links.  In  this  scheme, 
reporting  cells  are  defined  as  a  subset  of  the  cells.  A  mobile  terminal  reports  its  location 
only  when  entering  one  of  these  reporting  cells.  When  an  incoming  call  arrives,  the  source 
terminal  starts  searching  from  the  cell  where  the  destination  terminal  last  reported  its 
location.  Finding  an  optimal  set  of  reporting  cells  has  been  shown  to  be  a  NP-complete 
problem.  Moreover,  this  scheme  doesn’t  consider  the  call  arrival  and  movement  patterns  of 
individual  mobile  terminal.  For  example,  a  mobile  terminal  located  near  the  boundary  of 
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two  reporting  cells  may  have  to  report  the  location  update  whenever  it  crosses  the  boundary, 
even  if  the  arrival  probability  of  incoming  call  is  low. 

The  same  authors  of  [BaK93]  also  proposed  another  three  tracking  strategies  for  mobile 
users  in  wireless  network:  Distance-Based  Update,  Movement-Based  Update,  and  Time- 
Based  Update  [BaK94].  In  the  Distance-Based  Update  model,  the  user  location  updates  are 
performed  based  on  the  distance  (denoted  by  D)  between  its  current  cell  and  the  cell  in 
which  it  last  reported.  In  a  same  manner,  location  update  of  Movement-Based  model  is 
performed  whenever  it  completes  M  movements  between  cells.  In  Time-Based  model 
location  update  is  just  performed  every  T  time  slots. 

In  terms  of  implementation  overhead,  the  time-based  strategy  is  the  simplest  since 
mobile  terminals  only  have  to  send  update  message  according  to  their  local  clocks.  The 
movement-based  strategy  is  more  difficult  to  implement  since  mobile  terminals  have  to 
count  the  number  of  movement  whenever  they  cross  boundaries  between  cells.  The 
distance-based  strategy  is  most  difficult  to  implement  because  all  mobile  terminals  have  to 
know  about  the  topology  of  cells  in  order  to  calculate  the  distance. 

In  each  method,  the  expected  number  of  update  messages  per  slot  transmitted  by  a  user 
and  the  expected  number  of  searches  necessary  to  locate  a  user  were  calculated.  The 
numerical  results  of  this  paper  showed  that  the  distance-based  strategy  requires  2.5  times  less 
update  rate  than  two  other  strategies  do  for  achieving  a  cost  of  search  equals  to  3,  even 
though  it  required  the  highest  overhead  in  its  implementation. 
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Akyildiz  and  Ho  suggested  a  novel  dynamic  user  location  update  mechanism  [AkH95]. 
According  to  this  paper,  a  mobile  terminal  dynamically  determines  when  to  update  after 
moving  to  a  new  cell  based  on  its  mobility  pattern  and  the  incoming  call  arrival  probability. 
The  key  idea  behind  this  mechanism  is  that  it  updates  user  location  just  before  its  update1 
cost  becomes  greater  than  paging2  cost.  In  other  words,  if  the  paging  cost  is  less  than  the 
location  update  cost,  location  update  is  no  longer  needed.  By  using  expected  paging  cost 
and  location  update  cost  according  to  the  movement  pattern  of  terminal  user,  the 
mechanism  can  calculate  the  expected  next  update  time.  The  algorithm  also  calculates  the 
call  arrival  probability  that  is  used  to  find  the  next  update  time,  by  collecting  the  previous  call 
arrival  information  at  the  registers  of  mobile  terminals. 

Since  all  the  papers  mentioned  before  talk  about  ULU  strategies  under  the  cellular 
network  systems,  it  is  very  difficult  to  say  that  which  strategy  is  adequate  for  satellite  network 
system  without  any  experiment.  Compare  to  cellular  network  system,  the  boundary  of 
satellite  network  system  is  much  larger  and  unit  area  size  needed  location  update  is  not 
known  yet.  Also,  the  mobility  pattern  of  mobile  terminals  of  the  satellite  network  will  not  be 
same  as  that  of  cellular  network  since  the  purpose  of  satellite  network  system  is  global 
communication  and  that  of  cellular  network  system  is  local  communication. 

One  paper  published  in  March  1997  compares  satellites  network  systems  and  cellular 
network  systems  in  terms  of  location  update  and  call  setup  procedure  ]Hub97].  This  paper 

1  Updating  cost  represents  each  cost  for  updating  user  location  and  this  is  independent  of  the  location  of  the  mobile  terminal. 

2  Paging  cost  represents  the  cost  for  polling  each  cell  during  the  terminal  paging  process. 
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concludes  that  the  methods  used  for  location  update,  call  setup,  call  handoff,  and  cell  reuse 
are  surprisingly  similar,  even  though  the  two  systems’  architectures,  services  provided,  and 
subscriber  number  formats  very  enormously. 

According  to  [Hub97],  all  user  location  information  is  managed  by  each  gateway.  All 
mobile  users  are  registered  to  their  Home  Gateway.  Whenever  mobile  users  enter  into  a 
new  gateway  area,  they  send  update  signals  to  Visited  Gateway.  Visited  Gateway  adds 
visiting  mobile  user  information  to  its  visited  location  register  (VLR)  database  and  sends 
current  location  information  of  visiting  mobile  user  to  his/her  Home  Gateway.  Then,  the 
Home  Gateway  of  visiting  mobile  user  updates  its  home  location  register  (HLR). 

In  order  to  connect  to  the  Iridium  mobile  user  roaming  in  a  Visited  Gateway,  the  call 
signal  is  first  routed  to  the  Home  Gateway  of  mobile  user  via  the  PSTN.  From  the  HLR  in 
the  Home  gateway,  a  call  signal  retrieves  the  Visited  Gateway  information  of  mobile  user 
and  reroutes  the  call  signal  to  the  Visited  Gateway  via  the  Iridium  satellite  crosslink  system. 
The  Visited  Gateway  looks  in  the  VLR  to  identify  the  mobile  user’s  location  and  reroute  the 
call  signal  to  the  satellite  directly  over  the  destination  mobile  user. 

The  user  location  update  strategy  used  in  this  paper  is  similar  to  Movement-Based 
update  strategy  [Bak94],  where  the  movement  is  defined  as  crossing  over  the  gateway 
boundary.  But,  the  optimized  size  of  one  gateway  boundary  or  required  number  of 
gateways,  which  can  be  a  very  important  factor  in  terms  of  system  performance,  is  not 
discussed  in  this  paper. 
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2.5  Summary 

limited  work  has  been  found  in  the  open  literature  related  to  ULU/ULD  strategies 
proposed  for  PCS  network.  Among  them,  only  [Hub97]  provided  a  big  picture  of  LEO- 
based  ULU/LUD  concept.  In  order  to  adapt  the  ULU/ULD  strategies  discussed  above  to  a 
satellite  network  environment,  the  satellite  is  considered  to  be  a  reporting  cell  in  the  cellular 
system.  Even  though  satellites  are  moving  at  a  high  velocity  (1200  m/ s),  at  least  one  satellite 
can  cover  a  certain  area  without  disconnection.  If  we  assume  that  the  satellite  gracefully 
hands  all  the  communication  link  information  over  the  next  satellite,  we  can  also  regard 
those  many  traveling  satellites  as  one  fixed  satellite  working  continuously  over  one  specific 
area.  This  assumption  leads  the  satellite  communication  system  to  be  the  same  as  a  cellular 
network  system.  Based  on  this  assumption,  new  ULU/ULD  algorithms  are  developed  for 
LEO  satellite  network  systems.  In  next  Chapter,  the  standard  of  a  user  location  tracking 
scheme  in  cellular  network  systems  (TS-41)  is  reviewed  and  then  two  user  location  tracking 
algorithms  are  derived  based  on  IS-41  standard. 
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3.  ALGORITHM  DERIVATION 


3. 1  Introduction 

Before  mentioning  ULU/ULD  algorithms  for  LEO  satellite,  the  current  cellular 
network  standards  are  examined  in  order  to  get  a  basic  understanding  of  the  cellular  network 
systems.  Because  both  cellular  and  satellite  network  system  are  working  under  the  mobile 
communication  environment  [Log95],  common  aspects  exist  in  terms  of  overall  system 
architectures.  After  discussing  these  commonalties,  a  new  ULU/ULD  algorithms  for  LEO 
satellite  network  is  introduced.  A  discussion  of  the  simulation  models  developed  to  analy2e 
and  compare  the  performance  of  these  algorithms  follows. 

3. 2  User  Location  Management  S tandard  of  Cellular  'Network  (IS -41) 

3.2. 1  Database  Managed  by  IS -41 

IS-41  protocol  is  a  public  communications  network  (PCN)  location  management 
standard  for  North  America  area  and  this  algorithm  is  performing  based  on  two-level 
database  hierarchy  [ETA91].  Two  types  of  database,  home  location  register  (HLR)  and 
visitor  location  register  (VLR),  are  used  to  store  the  location  information  of  the  mobile 
terminals.  According  to  the  IS-41  location  strategy,  the  cellular  network  system  maintains  all 
the  user  information  as  follows. 

•  Each  cell  has  its  own  base  station  (BS)  and  one  registration  area  (RA)  is  consist  of 
several  cells.  All  cells  are  wired  to  a  mobile  switching  center  (MSC). 

•  Each  registration  area  (RA)  has  a  mobile  user  information  under  its  area.  This 
database  is  called  visitor  location  register  (VLR)  and  co-exist  with  MSC 
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•  All  the  information  in  the  VLR,  in  turn,  will  be  transmitted  to  the  home  location 
register  (HLR). 

3.2.2  User  Location  Update  (ULU)  Procedure 

Using  these  databases  (HLR,  VLR),  mobile  users  update  their  latest  location  information 
whenever  they  enter  into  the  new  register  area.  The  operation  of  the  ULU  procedure  is  as 
follows.  : 

•  Each  Mobile  User  updates  their  location  to  the  nearest  BS  whenever  they  move  into 
new  RA.  (Updating  time  varies  according  to  updating  algorithm.) 

•  The  BS  forwards  this  message  to  the  new  serving  MSC. 

•  The  new  MSC  updates  its  associated  VLR,  indicating  that  the  mobile  terminal  is  now 
residing  in  its  service  area  and  sends  a  location  registration  message  to  the  HLR. 

•  The  HLR  sends  a  registration  acknowledgment  message  to  the  new  MSC/VLR 
together  with  a  copy  of  the  subscriber’s  user  profile. 

•  The  HLR  sends  a  registration  cancellation  message  to  the  old  MSC/VLR. 

•  The  old  MSC  removes  the  record  for  the  mobile  terminal  at  its  associated  VLR  and 
send  a  cancellation  acknowledgment  to  the  HLR. 

3.2.3  User  Location  Determination  (ULD)  Procedure 

From  the  previous  procedure,  it  can  be  seen  that  HLR  always  know  the  location  of  all 
mobile  users.  So,  the  mobile  user  (or  non-mobile  user)  can  easily  find  the  destination  mobile 
user  by  searching  the  HLR  database.  The  detailed  ULD  procedure  is  as  follows. : 

•  The  railing  mobile  terminal  sends  a  call  initiation  signal  to  its  serving  MSC  through 
the  nearby  BS. 
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•  The  MSC  of  the  calling  mobile  terminal  sends  a  location  request  message  to  the 
HLR  of  the  mobile  terminal. 

•  The  HLR  determines  the  cell  location  of  the  called  mobile  terminal  and  sends  a 
route  request  message  to  this  MSC. 

•  The  MSC  determines  the  cell  location  of  the  called  mobile  terminal  and  assigns  a 
temporary  location  directory  number  (TLDN)  to  the  called  mobile  terminal.  The 
MSC  then  sends  this  TLDN  to  the  HLR 

•  The  HLR  sends  the  TLDN  to  the  MSC  of  the  calling  mobile  terminal.  The  calling 
MSC  can  now  setup  a  connection  to  the  called  MSC  through  the  PSTN. 

3.3  Choice  of  User  location  Update  Method 

In  this  thesis,  no  new  ULU  method  for  satellite  network  systems  is  introduced,  the 
Movement-Based  update  method  from  [Bak94]  is  selected  for  examination  since  it  is  both 
cost-effective  and  feasible  to  implement.  The  movement  threshold  was  set  to  1,  which 
represents  that  the  mobile  user  updates  it  location  whenever  he/ she  crosses  new  RA. 

In  real  life,  these  RAs  (coverage  areas)  may  be  distinguished  by  geopolitical  relationship 
or  may  be  divided  by  geographical  position.  In  this  thesis,  a  geographical  division  method  is 
applied  since  geopolitical  division  requires  more  detail  political  information  about  global  area 
and  this  makes  the  simulation  implementation  impossible  at  this  point.  The  method  of 
geographical  division  is  explained  at  the  end  of  this  chapter  in  Section  3.8. 

3.4  Basic  Requirements  Needed  for  Dynamic  User  location  Determination 

As  previously  mentioned,  in  order  to  find  the  destination  mobile  user  immediately 

(without  using  flooding  search),  some  mechanism  have  to  keep  track  of  all  mobile  users  and 
provide  the  mobile  user  information  when  it  is  needed  by  another  user.  Under  the  cellular 
network  environment,  all  the  mobile  users  update  their  current  location  as  they  move  and 
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those  information  are  maintained  in  each  registration  areas  (RAs)  in  the  form  of  VLR  and 
HLR.  VLR  contains  only  regional  user  information,  while  HLR  contains  all  the  user  profiles 
in  its  whole  system.  Likewise,  for  the  mobile  satellite  network  system,  there  is  a  need  to  put 
all  the  information  of  satellite  network  users  in  a  place  (or  many  places)  where  all  the  mobile 
users  can  dynamically  retrieve  the  information.  The  most  likely  choice  for  this  storage  place 
is  gateways  or  satellites. 

3.4. 1  The  Places  for  Saving  User  Information 

Gateways  almost  have  no  limit  on  memory  space  and  computational  ability  related  with 
satellite  positioning  and  routing,  database  searching  and  updating.  As  many  satellite  network 
systems  are  aiming  for  global  communication  capability,  it  seems  to  be  very  hard  to  maintain 
all  the  mobile  user  information  at  one  place.  One  simple  answer  for  this  problem  is  that  all 
the  mobile  satellite  user  information  can  be  managed  distributively  by  several  gateways  that 
are  located  in  different  locations  around  the  world.  In  other  words,  each  gateway  is  only 
taking  care  of  mobile  users  who  are  currendy  traveling  within  the  boundary  of  each  gateway. 
This  can  reduce  not  only  the  message  traffics  between  the  gateway  and  the  adjacent  satellite, 
but  also  call  setup  delay.  Nevertheless,  we  can  still  expect  some  bottleneck  near  to  gateways, 
because  of  frequent  access  to  gateways. 

Another  possible  place  for  holding  the  user  information  database  is  within  each  orbiting 
satellite.  Each  satellite  in  the  system  can  work  as  gateway.  These  satellites  have  limited 
memory  space  and  computational  ability  compare  to  gateways.  But  there  exists  a  few 
advantages  of  this  approach  if  we  overcome  the  memory  and  computation  limitations.  One 


16 


advantage  is  that  we  can  remove  the  bottleneck  from  the  entire  system.  This  is  due  to  the 
fact  that  there  is  no  need  to  access  a  gateway  for  the  purpose  of  location  update  or  call 
setup.  Another  advantage  is  that  we  can  also  expect  the  reduced  call  setup  delay  compare  to 
the  gateway  approach.  Because  the  call  request  can  be  directly  routed  to  the  destination 
satellite  without  connecting  to  the  terrestrial  gateways,  the  total  setup  delay  can  be  reduced 
by  at  least  two  times  of  up/ down  link  delay. 

3.4.2  Area  to  Satellite  Table  (AST) 

Satellite  network  topology  used  for  this  investigation  is  changing  with  a  uniform  pattern 
and  repeats  infinitely.  This  means  that  we  can  calculate  the  position  of  each  satellite  or  find 
it  using  pre-calculated  topology  table  for  a  given  time  slot  [ChK95].  If  the  global  area  can  be 
divided  into  many  small  areas  called  Iridium  Registration  Area3  (IRA),  then  a  match  can  be 
made  for  an  IRA  to  satellites  that  can  completely  or  partly  cover  the  given  area  during  one 
time  slot.  The  maximum  size  of  one  IRA  must  be  smaller  than  one  satellite’s  footprint  size 
in  order  to  cover  one  IRA  with  only  one  satellite.  And  also  some  IRA  cannot  be  covered 
entirely  by  one  satellite  for  a  given  time  slot,  if  the  IRA  is  located  in  the  boundary  area 
between  two  or  more  satellites’  footprint.  In  that  case,  one  IRA  can  be  covered  by  more 
than  two  satellites.  Using  previous  assumptions,  we  can  build  a  ‘Area4  to  Satellite  Table 
(AST)’  for  a  given  time  slot.  Each  IRA  is  mapped  to  satellites  that  are  completely  or  partly 
covering  the  IRA.  This  table  can  be  obtained  by  calculating  the  distance  between  IRA  and 


3  An  area  which  has  its  own  Iridium  Area  Code 

4  Area  implies  a  Iridium  Registration  Area. 


17 


satellites  which  can  be  visible  from  the  IRA,  and  set  the  closest  satellite  to  the  highest 
priority.  Maximum  number  of  satellites  needed  to  cover  one  IRA  can  be  varied  according  to 
its  position  or  satellite  topology.  Thus,  this  value  is  not  determined,  yet.  Table  1  shows  a 
example  of  ‘Area  to  Satellite  Table  (AST)’  for  one  time  period.  This  AST  must  be  updated 
continuously  as  the  satellites  move.  This  implies  that  each  satellite  must  have  a 
computational  ability  to  update  the  AST  within  a  given  update  interval. 


Table  1  Area  to  Satellite  Table  for  1  time  slot 


IRA-ID 

SAT-ID 

(Priorityl) 

SAT-ID 

(Priority2) 

SAT-ID 

(Priority3) 

.... 

1 

Si 

s2 

S3 

.... 

2 

s2 

S3 

S4 

: 

; 

: 

* 

.... 

: 

; 

: 

* 

.... 

R 

s6 

S7 

S8 

.... 

If  we  are  using  a  flooding  type  of  algorithm,  we  only  need  AST  tables  that  can  be  used 
for  the  starting  point  (satellite)  of  searching  destination  user. 

3.4.3  Logical  Home  Satellite  (LHS) 

Whenever  the  new  mobile  user  registers  in  the  satellite  network  system,  the  new  user  will 
be  given  a  unique  User-ID  that  will  be  similar  to  the  current  telephone  numbering  system. 
This  User-Id  will  then  need  to  be  saved  to  the  nearest  gateway  station  or  nearest  satellite 
passing  over  the  user’s  home  area  (initial  area).  In  a  satellite  network  system  all  satellites  are 
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moving  with  a  high  velocity  relative  to  the  user.  Therefore,  the  satellite  cannot  function  like 
base  station  (BS)  in  a  cellular  system.  Each  area  can  find  at  least  one  best  satellite  at  any  time 
slot  from  the  AST  table.  This  satellite  is  considered  to  be  the  logical  home  satellite  (LHS). 
Moreover,  one  satellite  can  work  as  the  LHS  for  multiple  IRAs  if  the  footprint  of  that 
satellite  covers  many  IRAs.  Thus,  each  satellite  works  as  LHS  of  its  footprint  area,  and  the 
LHS  of  one  specific  IRA  is  continuously  changing  as  the  satellite  moves.  We  assume  that 
the  information  on  mobile  users  of  each  IRA  will  be  managed  by  its  LHS  and  the 
information  will  be  gracefully  handed  over  to  the  next  LHS  as  time  changes. 

3.4.4  Home  Area  (HA)  /  Home  Gateway  (HG) 

Normally,  one  gateway  can  cover  more  areas  than  one  LHS  can  if  the  number  of 
gateways  is  less  than  that  of  satellites.  When  a  new  mobile  user  registers  with  a  satellite 
network  system,  he  will  get  an  IRA-ID  and  User-ID.  This  IRA-ID  will  be  the  user  s  home 
area  and  the  area  will  be  subordinated  to  a  nearest  gateway,  which  will  be  the  user’s  home 
gateway.  Thus,  each  mobile  user  will  have  its  own  home  area  (HA),  logical  home  satellite 
(LHS),  and  home  gateway  (HG)  as  soon  as  he  enrolls  to  the  system. 

3.4.5  Databases  Needed  in  Satellite  Network  System 

Like  a  cellular  system,  two  tables  need  to  be  maintained  by  HGs  (or  LHSs).  The  first 
one  is  absent  user  table  (AUT).  This  table  contains  the  list  of  mobile  users  who  are  traveling 
out  of  their  home  area  (HA)  and  their  last  reported  current  IRA-ID.  Table  2  shows  an 
example  of  absent  user  table  (AUT).  For  instance,  if  User-1  and  User-2  of  Area-A  are 
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traveling  out  of  their  home  area,  the  AUT  of  home  gateway  (HG)  or  logical  home  satellite 
(LHS)  will  be  updated  as  soon  as  they  report  their  current  Area-ID. 

Second,  the  information  of  visitors  who  came  from  the  other  area  is  known.  This  table  is 
Table  2  Absent  User  Table  (AUT)  of  Area-A's  home  gateway  (or  LHS) 


User-ID 

Current  IRA-ID 

User-1 

Area-D 

User-2 

Area-F 

: 

: 

named  the  visiting  user  table  (VUT)  and  contains  the  visiting  user  list  and  their  home  IRA- 
ID.  Table  3  shows  an  example  of  visiting  user  table  (VUT).  From  the  previous  example, 
User-l’s  data  is  added  to  visiting  user  table  (VUT)  in  home  gateway  (or  LHS)  of  Area-D 
right  after  he  requested  his  location  update.  After  updating  the  VUT,  the  home  gateway  (or 
LHS)  of  Area-D  sends  the  visitor’s  current  location  information  to  visitor’s  home  gateway 


Table  3  Visiting  User  Table  (VUT)  of  Area-D's  home  gateway  (or  LHS) 


User-ID 

Home  IRA-ID 

User-1 

Area-A 

User-3 

Area-B 

: 

• 

: 

: 
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(or  LHS)  in  order  to  update  its  AUT. 


3.5  User  Location  Determination  Algorithm  for  Satellite  Network  System 

In  this  section,  two  ULD  algorithms  are  proposed  for  satellite  network  systems.  The 

first  algorithm  uses  HGs  for  user  information  storage  while  the  second  uses  LHSs.  But, 

both  algorithms  have  a  same  concept  in  a  sense  that  all  mobile  users  are  updating  their 

recent  location  to  the  nearest  storage  place  (HG  or  LHS)  and  call  request  paging  starts  from 

destination  user’s  last  updated  area. 

3.5. 1  Gateway  Approach 

In  this  algorithm,  user  information  tables  (AUT  and  VUT)  are  saved  in  the  gateways 
which  are  located  in  many  different  places  over  the  world.  These  gateways  will  also  be  used 
as  the  access  point  from  terrestrial  networks  to  satellite  networks  (or  vice  versa).  Because  of 
the  unlimited  memory  space  of  gateways,  one  gateway  can  hold  as  much  data  as  needed. 
However,  as  the  number  of  mobile  users  that  are  managed  by  one  gateway  increases, 
message  traffic  to  the  gateway  will  also  increase.  Thus,  there  is  a  trade-off  between  the 
number  of  gateways  and  message  congestion.  This  relationship  is  examined  with  the  results 
discussed  in  Chapter  4. 

3.5.1 .1  Location  Update  Procedure 

*t*  Whenever  a  mobile  user  enters  into  the  new  IRA,  the  User-ID  and  Home  IRA-ID 
are  reported  to  the  new  IRA’s  home  gateway  (HG). 

♦♦♦  The  gateway  updates  visiting  user  table  (VUT)  of  the  new  IRA. 

♦♦♦  If  the  home  gateway  (HG)  of  the  visitor  is  same  as  that  of  new  IRA, 
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♦  Then,  the  gateway  updates  the  absent  user  table  (AUT)  of  the  visitor’s  home 
area  (HA). 

♦  Else,  the  gateway  sends  the  visitor’s  Current  IRA-ID  to  his  home  gateway  (HG) 
and  update  the  absent  user  table  (AUT)  of  visitor’s  home  area  (HA). 

3.5.1 .2  Call  S etup  Procedure 

Let’s  assume  that  mobile  user  1  (MUl)  tries  to  communicate  with  mobile  user  2  (MU2) 
via  satellite  network.  The  nearest  satellite  of  MUl  will  be  the  start  satellite  (S-SAT)  of  the 
connection  path  and  that  of  MU2  will  be  the  end  satellite  (E-SAT). 

♦♦♦  MUl  sends  a  call  setup  request  to  S-SAT. 

♦♦♦  S-SAT  sends  the  call  setup  request  to  MU2’s  home  gateway  (HG). 

♦♦♦  If  MU2’s  home  gateway  (HG)  finds  his  User-ID  in  the  AUT, 

♦  Then,  the  nearest  satellite  from  MU2’s  current  IRA  will  be  the  E-SAT  and  the 
call  setup  request  will  be  rerouted  to  the  E-SAT. 

♦  Else,  the  nearest  satellite  from  MU2’s  home  IRA  will  be  the  E-SAT  and  the  call 
setup  request  will  be  rerouted  to  the  E-SAT. 

♦♦♦  Page  the  call  request  from  the  E-SAT. 

♦J4  If  MU2  replies, 

♦  Then,  call  setup  is  established. 

♦  Else,  reroute  the  call  setup  request  to  next  priority  E-SAT  and  page  the  call 
setup  request  until  the  MU2  replies. 

3.5.2  Satellite  Approach 

In  this  algorithm,  LHSs  are  used  as  the  storage  place  instead  of  gateways. 

3.5.2. 1  Location  Update  Procedure 

♦♦♦  Whenever  a  mobile  user  enters  into  the  new  IRA,  he  reports  his  User-ID  and  Home 
IRA-ID  to  the  new  IRA’s  LHS. 

♦♦♦  The  new  IRA’s  LHS  updates  its  visiting  user  table  (VUT). 
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The  new  IRA’s  LHS  sends  the  visitor’s  Current  IRA-ID  to  his  LHS  and  updates  the 
absent  user  table  (AUT). 

3. 5. 2. 2  Call  Setup  Procedure 

Let’s  assume  that  mobile  user  1  (MU  1)  tries  to  communicate  with  mobile  user  2  (MU2) 
via  satellite  network.  The  nearest  satellite  of  MU1  will  be  the  stars  satellite  (S-SAT)  of  the 
connection  path  and  that  of  MU2  will  be  the  end  satellite  (E-SAT). 

♦♦♦  MU1  sends  a  call  setup  request  to  S-SAT. 

*t*  S-SAT  sends  the  call  setup  request  to  MU2’s  LHS 
❖  If  MU2’s  LHS  finds  his  User-ID  in  the  AUT, 

♦  Then,  the  nearest  satellite  from  MU2’s  current  IRA  will  be  the  E-SAT  and  the 
call  setup  request  will  be  rerouted  to  the  E-SAT. 

♦  Else,  the  MU2’s  LHS  will  be  the  E-SAT  and  no  reroute  is  needed. 

♦♦♦  Page  the  call  request  from  the  E-SAT. 

*1*  If  MU2  replies, 

♦  Then,  call  setup  is  established. 

♦  Else,  reroute  the  call  setup  request  to  next  priority  E-SAT  and  page  the  call 
setup  request  until  the  MU2  replies. 

3.6  Simulation  Construction 

The  network  simulation  models  used  in  this  thesis  were  built  using  two  packages, 
BoNES  Designer  and  SatLab,  published  by  Cadence  software.  Designer  is  a  top-down 
block-oriented  network  simulation  package  and  SatLab  is  a  satellite  constellation  simulation 
and  optimization  package.  SatLab  is  used  to  communicate  the  relative  positioning  and 
visibility  information  of  each  network  node  to  Designer,  and  comes  with  the  Globalstar  and 
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Iridium  constellations  built  in.  Since  only  Iridium  system  has  inter-satellite  link  processing 
ability,  Iridium  constellation  is  the  topology  chosen  for  the  simulation. 

3.6.1  Satellite  Approach 

Figure  4  is  a  block  diagram  of  the  Satellite  Approach  simulation.  Text  labeled  with  an  “M” 
is  a  memory  variable,  and  the  text  labeled  with  an  “P”  is  a  simulation  parameter  set  at 
runtime. 

Detail  parameter  values  and  memory  variable  functions  are  explained  in  Appendix  A. 
The  simulation  is  composed  of  two  main  parts:  positioning  and  communicating.  Positioning 


User  Location  Determination-Satellite  Approach  [  15-Oct-1997  15:52:27  ] 


[POSITIONING] 

Start  ' 


fFI  Relative  Order 

m 


I  [nit  SHBEIog 


aF?-|©^ 


System  ^ 

Update  © 

Time  Delay 


U  Update  ra 
R  Satellite 


Update 

1  MoblleUser 


[COMMUNICATING] 


Traffic  r>| 
Generator  1 


Find  Start-SAT 
and  End-SAT 


Route  from  ^ 

>  SAT  to  > 

SAT 

Find  Destination 
User  Location 


|>  Page  from  >| — >  from  SAT  t>H> 


>H>  End-SAT  >\ 


L_  a  Add  Rejected  rJ* 
Traffic  \ 


Connection 

Established 


fp  Year 
ITp  Month 
fp  Day 
fp  Hour 
fp  Minute 
Up  Second 
fp  Area  Size 


fp  System  Update  Delay 
fp  Mean  Inter-Pulse  Time 
f  P  Earth  <->  SAT  Data  Rate 
f  p  SAT  <->  SAT  Data  Rate 
f  P  Antenna  mean  value 
fp  Antenna  angle 


[m!  Number  of  Nodes 

[m!  Number  of  Earthstations 

[m3  Number  of  MobileUsers 

ImI  Number  of  Satellites 

ImI  Distance  Table  Memory 

[iTlvisibility  Table  Memory 

[m3  Mobile  Latitude  Table  Memory 

[m!  Mobile  Longitude  Table  Memory 


ImI  Routing  Table  Memory 
[m3  Area  to  Satellite  Table(AST) 
M  Absent  User  Table(AUT) 

\m\  Visiting  User  Table(VUT) 
Im]  MobileUser  Position  Table 
[1^1  Number  of  Traffic  Rejected 
[m1  Number  of  Traffic  Passed 


Figure  4  Top  level  block  diagram  of  the  Satellite  Approach 
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part  initializes  all  communication  nodes  (satellites,  gateways,  and  mobile  users)  and  updates 
their  positions  by  requesting  node  information  to  SatLab  simulator.  Updating  is  performed 
every  time  period  given  by  the  parameter  System  Update  Delay  until  the  simulation  finishes. 

The  communications  portion  of  the  model  generates  call  request  traffic  based  on  a 
Poisson  arrival  rate,  and  routes  call  request  traffic  according  to  the  proposed  algorithm. 
After  the  call  setup  establishes,  the  call  request  traffic  disappears.  Detail  explanation  about 
simulation  process  is  presented  in  Appendix  A. 

3. 6. 2  Gateway  Approach 

Figure  5  is  a  block  diagram  of  the  Gateway  Approach  simulation.  The  simulation 
initializing  and  node  updating  portions  are  the  same  as  the  Satellite  Approach.  The  main 
difference  in  the  communications  portion  is  that  the  Satellite  Approach  first  routes  the  call 
setup  request  message  to  destination  user’s  LHS,  which  can  be  found  in  the  AST,  while  the 
Gateway  Approach  first  routes  the  call  setup  request  message  to  destination  user’s  home 
gateway  (HG). 

3.7  Data  Collection 

The  purpose  of  this  thesis  is  to  compare  the  performance  of  user  location  determination 
algorithms  that  can  be  applied  to  LEO  satellite  network  system.  Two  user  location 
determination  algorithms  were  presented  in  section  3.5.  The  two  algorithms  are  very  similar 
except  that  the  physical  location  of  user  database  is  different. 


25 


Initialize  System  [  15-Oct-1997  15:49:17  ] 


>1* 

_  i  BSIM  t>,  . _ |j 

>• 

V77>» 


P  E10  O 


>• 


3- 


J>  Nur 

|  ol  K 


5 


Number 
ot  Earthstations 


5 


£  >• 

>• 

4# 


Mobile  , 
Latitude  Bp 
Table 


Longiti 

Table 


Execute  ®| 
In  Order  B 


Read  Number 
ot  Satellites 


Read  Number 
of  Earthstations 


^T“ |>  I  Matrix  r>| _ | 

i — lt>  Create  ' 


H5T>T- 


1— H>  IMatrix  >Urt 
-1  Create  I  j; 


-|>  IMatrix 
Ht>  Create 


,  Int  Do  > 


tp  Year 
IfP  Month 
tP  Day 
tP  Hour 
tP  Minute 
tP  Second 
tP  Area  Size 


.  Write  Number  . 
[>  of  Traffic  ©T 


Write  Area 
to  Satellite 
Table 


Write  Visiting  ^  gj. 


User  Table(VUT) 


HE 

B-E 


User  Tablet AUTt 


Read  Mobile 
Longitude  >| 
A 


tM  Number  of  Nodes 
tM  Number  of  Earthstations 
tM  Number  of  MobileUsers 
tM  Number  of  Satellites 
tM  Mobile  Latitude  Table  Memory 
tM  Mobile  Longitude  Table  Memory 
tM  Area  to  Satellite  Table(AST) 
tM  Absent  User  Table(AUT) 
tM  Visiting  User  Table(VUT) 
tM  Mobile  User  Position  Table 
tM  Number  of  Traffic  Passed 


Read  Mobile 
Latitude  E> 
A _ 


T-l 


Convert  ** 
to  Area-ID  > 


Write  Mobile 
t>  User  Initial 
1  Position 
A  A 


Position 

A _ A 


Ljg  Synchronize 


-S 


<]  Synchronize  g|2 


Write  Mobile 
User  Initial 
Position 
A  A 

—I 


Figure  5  Top  level  block  diagram  of  the  Gateway  Approach. 

First,  the  most  important  comparison  measurement  of  two  algorithms  is  Call  Setup  Delay 
time  parameter,  which  represents  the  total  time  taken  for  source  user  to  find  a  destination 
user.  This  call  setup  delay  is  almost  proportional  to  a  Hop-Count  (the  total  number  of 
connections  from  node5  to  node  for  each  call  setup  procedure).  Using  these  two 
parameters,  we  can  compare  the  call  setup  speed  of  two  algorithms. 

Second,  the  total  number  of  messages  passing  through  each  satellite  during  the 
simulation  time  is  examined  in  order  to  calculate  the  processing  load  of  each  satellite.  By 

5  A  node  represents  all  sorts  of  terminals  that  consist  of  Satellite  Communication  Networks. 
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doing  this,  the  message  distribution  for  a  given  time  period  can  be  calculated  and  if  there  is 
any  bottleneck  point,  it  can  be  found  with  this  measurement. 

The  last  parameter  examined  is  the  memory  requirement  for  each  approach.  Practically, 
the  Gateway  Approach  doesn’t  have  any  problem  about  memory  size  for  the  user  database. 
But  the  Satellite  Approach  has  a  limitation  about  on-board  memory  size.  If  the  memory 
requirement  of  the  worst  case  exceeds  the  ability  of  current  satellite  manufacturing 
technique,  the  satellite  approach  cannot  be  adopted  no  matter  how  it  is  a  good  approach. 

3.8  Operational  Assumptions 

The  simulation  models  developed  for  this  thesis  are  constructed  under  a  set  of 
representative  assumptions. 

1.  The  area  size  for  one  unique  registration  area  (IRA)  was  evenly  divided  and  allocated 
according  to  the  longitude  and  latitude  range.  This  implies  that  the  size  of  all  registration 
areas  is  not  same  as  for  other  areas.  This  is  due  to  the  fact  that  the  length  of  longitude 
decreases  as  the  magnitude  value  of  latitude  increases,  the  registration  area  near  the  North 
Pole  (or  South  Pole)  is  smaller  than  that  of  the  equator  area.  This  policy  was  taken  into 
account  as  the  SatLab  simulation  program  only  sends  the  geographic  coordinates  of  mobile 
users. 

2.  The  source  and  destination  users  are  selected  randomly  from  the  mobile  users  that 
are  evenly  positioned  across  the  globe  and  move  in  similar  fashion. 
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3.  The  user  location  update  process  is  not  precisely  simulated  as  explained  in  the 
previous  section.  In  real  life,  each  mobile  user  has  to  update  its  location  individually  as  it 
moves  to  new  registration  area.  But  in  this  simulation,  the  user  location  update  process  is 
performed  with  the  fixed  update  interval  time  because  of  the  limitation  related  with  SatLab 
positioning  request  function.  In  SatLab  program,  node  location  update  is  performed  by 
node  group  (satellite  group,  earth  station  group,  and  mobile  user  group)  and  single  node 
cannot  be  updated  individually.  Thus,  the  message  traffic  related  with  the  location  update 
process  is  not  taken  into  account  for  simulation  construction. 

4.  Call  setup  delay  is  obtained  by  accumulating  propagation  delay  and  transmission 
delay.  A  further  assumption  is  that  there  was  no  queuing  delay,  and  no  processing  delay, 
during  the  entire  simulation.  Also,  assumed  is  no  user  replying  delay.  However,  the 
comparison  of  processing  delay  between  two  different  approaches  is  discussed  in  Chapter  4. 

5.  The  routing  algorithm  used  in  this  simulation  was  provided  by  BoNES  SatLab 
program  builder.  Since  the  matter  of  routing  algorithm  in  LEO  satellite  network  is  beyond 
the  scope  of  this  research,  the  efficiency  of  this  built-in  routing  function  is  not  discussed.  It 
should  be  understood  that  the  routing  algorithm  using  inter  satellite  links  is  one  of  the  most 
important  factor  in  the  LEO  satellite  network  system  and  must  be  developed  and  combined 
together  with  this  research. 
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3.9  Verification  /  Validation 

3.9.1  Designer  BDE  Verification 

Each  simulation  was  verified  by  BoNES  Designer’s  built-in  verification  function,  which 
implies  that  the  simulation  does  not  have  any  logical  construction  error.  However,  this  built- 
in  verification  function  cannot  confirm  whether  the  proposed  ULD  algorithms  are  correctly 
implemented  to  Designer  simulations.  For  this  reason,  each  call  request  was  given  a  serial 
number  and  kept  track  of,  using  interactive  simulation  option.  The  result  showed  that  each 
call  request  message  was  correctly  routed  to  destination  user  and  came  back  to  the  source 
user  as  explained  in  a  previous  section  (3.5  User  Location  Determination  Algorithm  for 
Satellite  Network  System). 

3.9.2  System  Validation 

Even  though  a  lot  of  LEO  satellite  network  systems  are  proposed  and  among  them. 
Iridium  system  is  planned  to  operate  in  1998,  detail  system  specifications  are  not  published 
yet  by  the  system  providers.  Thus,  simulations  constructed  in  this  thesis  are  based  on  the 
published  LEO  satellite  system  proposals  and  research  papers,  and  some  constants  (i.e. 
satellite  data  rates)  taken  from  the  Iridium  proposal  [FCC91]. 

3.10  Summary 

In  this  Chapter,  the  public  communications  network  (PCN)  location  management 
standard  for  North  America  area  was  presented  and  two  ULD  algorithms  for  satellite 
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network  environment  were  derived.  Also,  simulations  constructed  to  evaluate  the  two  ULD 
algorithms  were  explained.  In  next  Chapter,  simulation  results  and  analysis  of  the  two  ULD 
algorithms  are  discussed. 
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4.  RESULT  AND  ANALYSIS 


4. 1  Simulation  Execution 

Two  different  simulations  (one  for  Satellite  Approach  and  one  for  Gateway  Approach/)  were 
constructed  and  executed  with  three  different  area  sizes  for  each  simulation.  With  20°  of 
longitude  and  latitude  interval,  the  earth  can  be  divided  to  162  areas.  Also  with  15°  and  10°, 
it  can  be  divided  to  288  and  648  areas,  respectively. 

In  the  Gateway  Approach,  four  different  sets  of  gateway  data  were  given  and  executed 
independently.  In  each  data  set,  the  global  earth  was  divided  by  6,  8,  10  or  12  main  regions 
and  a  gateway  positioned  in  the  middle  of  each  region  regardless  of  geographical  location. 
Thus,  each  simulation  was  operated  with  6,  8, 10  and  12  gateways,  respectively. 

Each  simulation  ran  for  6000  sec  of  simulation  time,  which  is  the  same  as  one  orbital 
period  of  Iridium  satellite.  During  one  orbit  period,  each  satellite  can  have  a  same 
opportunity  of  having  message  traffic  in  terms  of  latitude  variation,  and  this  can  provide 
more  accurate  message  distribution  analysis  among  satellites. 

During  the  simulation  process,  relative  node  position  information  between  nodes  are 
calculated  and  saved  to  memory  by  the  SatLab  simulation  program.  The  size  of  memory  for 
this  table  requires  (number  of  satellites  +  number  of  mobile  users  +  number  of  area)2  data 
entries.  In  the  case  of  162  area  simulation,  248,004  values  must  be  calculated  every  60 
seconds. 
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4.2  Call  Setup  Performance  Analysis 
4.2. 1  Average  Delay 

Figure  6  shows  the  average  call  setup  delay  of  the  Satellite  Approach  and  Gateway  Approach. 
When  the  area  size  was  the  same  value,  average  call  setup  delay  of  Satellite  Approach  was 
0.022  seconds  less  than  that  of  Gateway  Approach.  The  main  reason  of  this  0.022  seconds 
time  difference  came  from  the  different  routing  path  between  the  two  approaches.  This 
implies  that  the  routing  path  of  Gateway  Approach  is  longer  than  that  of  Satellite  Approach. 

Also  in  both  approaches,  call  setup  delay  decreased  as  the  number  of  areas  increased. 
This  result  came  from  the  accuracy  of  E-SAT  selection.  In  other  words,  the  E-SAT  was 
selected  more  accurately  when  the  total  number  of  areas  was  large.  Table  4  shows  that  the 
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Figure  6  Call  Setup  Delay  vs.  Area  Size 
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Table  4  Probability  of  satellite  selection  as  the  number  of  area  varies 


Priority 

SAT  Approach 

GW  Approach) 

£ 

CD 

CD 

1 62Area 

288Area 

648Area 

1 62Area 

288Area 

648Area 

Priority=1 

91.071% 

95.461% 

97.375% 

90.830% 

95.444% 

97.491% 

Priority=2 

6.751% 

3.891% 

2.497% 

7.159% 

3.615% 

2.447% 

Priority=3 

2.078% 

0.599% 

0.128% 

1.951% 

0.891% 

0.063% 

Priority=4 

0.100% 

0.050% 

0.000% 

0.060% 

0.050% 

0.000% 

distribution  of  selected  satellites  according  to  the  area  size.  In  this  table,  priority  is  defined 
as  the  minimum  order  of  distance  between  the  center  position  of  each  area  and  satellites  that 
is  orbiting  within  a  line  of  sight  from  that  area. 

According  to  Table  4,  in  the  case  of  the  Satellite  Approach,  91.071%  of  call  setup  requests 
were  established  at  first  E-SAT  selection  with  162  area  division,  while  97.375%  of  call  setup 
requests  were  established  at  first  E-SAT  selection  with  648  area  division.  This  implies  that 
6.304%  of  more  call  setup  requests  with  162  area  division  had  to  be  rerouted  to  next  priority 
E-SAT  in  order  to  find  destination  user.  The  same  result  occurred  for  the  Gateway  Approach. 

Another  factor  that  can  vary  the  call  setup  delay  for  the  Gateway  Approach  is  number  of 
total  gateways  in  the  system.  Figure  7  shows  that  the  call  setup  delay  decreases  as  the 
number  of  gateway  increase  when  the  area  size  is  the  same.  This  result  reflects  that  the 
routing  path  of  the  call  setup  request  can  be  shortened  as  the  number  of  gateway  increases. 

From  a  viewpoint  of  call  setup  delay,  the  Satellite  Approach  outperforms  the  Gateway 
Approach  and  detail  area  allocation  results  in  better  performance  than  rough  area  allocation. 
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Figure  7  Call  Setup  Delay  vs.  Number  of  Gateway 

Also  in  the  case  of  the  Gateway  Approach,  call  setup  time  with  a  large  number  of  gateways  was 
faster  than  with  a  small  number  of  gateways. 

4.2.2  Average  Hop-Count 

Number  of  hops  during  a  call  setup  process  is  almost  proportional  to  the  call  setup  time 
in  average  case.  However,  more  examination  was  taken  into  account  in  order  to  find  the 
difference  in  routing  path.  Figure  8  shows  the  average  number  of  hop-count  during  all  call 
setup  process.  According  to  the  Figure  8,  average  hop-count  of  the  Satellite  Approach  was 
almost  three  hops  less  than  that  of  Gateway  Approach.  And  in  both  approaches,  hop-count 
decreased  as  the  number  of  areas  increased.  Also,  when  the  area  size  is  the  same,  average 
Hop  Count  decreases  as  the  number  of  gateway  increases  (Figure  9). 
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Hop  Count  vs.  Area  size 
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Figure  8  Hop  Count  vs.  Area  Size 


By  looking  at  the  Gateway  Approach  algorithm,  it  is  expected  that  at  least  two  more  hops 
would  be  required  compare  to  the  Satellite  Approach.  This  is  because,  in  the  Gateway  Approach, 
the  call  setup  request  must  downlink  to  the  gateway  in  order  to  access  the  user  location 
database  and  uplink  to  the  satellite  again. 

The  remaining  difference  in  the  setup  delay  (excluding  2  hop-count)  came  from  the 
route  discrepancy  between  two  approaches  which  can  vary  according  to  mobile  users 
moving  pattern.  If  mobile  users  are  primarily  roaming  around  their  home  area,  the  Gateway 
Approach  will  have  a  higher  hop  count.  If  mobile  users  are  primarily  roaming  around  the 
Gateway  Area,  the  result  will  be  reversed.  If  mobile  users  are  traveling  far  from  their  home 
area  or  gateway,  the  difference  will  be  decreased. 
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Figure  9  Hop  Count  vs.  Number  of  Gateway 


4.2.3  Overall  Performance 

From  the  results  in  previous  sections,  the  Satellite  Approach  showed  better  performance 
than  the  Gateway  Approach  in  terms  of  call  setup  delay  and  number  of  hop-count.  In  the  case 
of  the  Gateway  Approach,  call  setup  delay  was  decreased  as  the  number  of  gateways  increased. 

4.3  Memory  Requirement  for  the  Satellite  Approach 

Whereas  the  Gateway  Approach  doesn’t  have  any  limitations  associate  with  memory  size 

for  the  user  information  database,  the  Satellite  Approach  is  limited  in  its  on-board  memory 
capacity.  This  requires  a  more  optimized  user  information  database  structure  in  order  to 
minimize  the  memory  requirement  of  the  Satellite  Approach.  In  other  words,  satellites  only 
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have  to  store  minimum  data  related  with  user  location  and  the  rest  of  the  information  (e.g. 
user  profiles,  billing  information,  etc.)  still  can  be  stored  in  gateways. 

4.3. 1  Area  to  Satellite  Table  (AST) 

Each  satellite  updates  the  AST  using  an  embedded  calculating  function  and  the  size  of 
this  table  will  be  ( number  of  areas  *  minimum  number  of  satellites  visible  from  one  area  *  bit  si%e  of 
SAT-ID).  From  the  Table  4  in  previous  section,  in  case  of  Iridium  satellite  network  system, 
four  nearest  satellites  from  the  center  of  IRA  are  required  for  two  different  area  allocation 
simulations  (162  IRA  and  288  IRA)  and  three  nearest  satellites  are  required  for  one 
simulation  (648  IRA).  Satellite-ID  requires  only  7  bits  in  order  to  distinguish  66  satellites. 

For  example,  in  the  case  of  162  area  division  with  66  Iridium  satellites,  each  IRA 
requires  four  nearest  satellite  table.  These  values  yield  total  size  of  4536  (162x4x7)  bits  for  a 
162-area  division.  Also,  for  the  288-area  and  648-area  divisions,  total  size  of  8064  (288x4x7) 
bits  and  13608  (648x3x7)  bits  result,  respectively.  Thus  the  maximum  size  needed  for  AST 
is  at  most  1701  bytes  and  this  value  is  almost  negligible. 

4.3.2  Absent  User  Table  (AUT) 

The  size  of  AUT  is  totally  dependent  on  the  number  of  subscribers,  user  mobility 
pattern,  geographical  location,  and  geopolitical  position.  And  at  this  point,  even  if  a 
prediction  can  be  made  of  the  number  of  subscribers,  the  mobility  pattern  cannot  be 
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achieved.  Thus,  the  worst  case  of  scenario  is  applied  to  determine  the  maximum  memory 
requirement  for  each  satellite. 

AUT  has  two  fields,  User-ID  and  Area-ID.  Thirty  bits  of  User-ID  can  distinguish  a 
maximum  of  1  billion  of  users  and  10-bits  of  Area-ID  can  provide  1024  unique  area  code. 
Let’s  suppose  that  10  millions  of  world-wide  subscribers,  which  is  the  declared  target  of 
Iridium  system  [Gav97],  use  Iridium  phones  and  all  the  users  are  currently  out  of  their 
Home  Area.  Let’s  suppose  all  the  users  were  originally  registered  to  one  Home  Area  in 
worst  case,  one  Home  satellite  contains  all  the  User-ID  in  its  AUT.  This  worst  case  of  one 
AUT  size  turns  out  to  be  less  than  50  Mbyte  (10million*40bit)  for  one  satellite. 

4.3.3  Visiting  User  Table  (VUT) 

The  total  number  of  absent  users  over  the  globe  is  always  the  same  as  total  number  of 
visiting  users.  So,  the  worst  case  is  that  all  the  mobile  users  are  visiting  one  area  from  all 
over  the  world  and  the  size  of  VUT  will  be  the  same  as  worst  case  of  AUT. 

4.3.4  Total  Memory  Si%e  Required 

The  size  of  AST  is  small  in  comparison  to  the  size  of  AUT  or  VUT.  And  also  the  total 
size  of  AUT  and  VUT  in  one  satellite  can  never  exceed  the  total  number  of  mobile  users. 
Thus  the  maximum  memory  size  required  for  satellite  approach  turns  out  to  be  50  Mbyte  of 
memory. 
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4.4  Processing  Delay  Associated  with  Data  Access 

Iridium  is  currendy  the  only  LEO  satellite  system  having  on-board  processing  and 

routing  capability  through  the  inter-satellite  links.  The  processing  delay  at  each  intermediate 
satellite  will  be  the  same  regardless  of  user  location  determination  algorithm.  The  difference 
in  processing  delay  happens  when  the  call  setup  procedure  tries  to  access  AUT  or  VUT.  In 
most  case,  the  seek  time  increases  as  the  size  of  database  increase. 

In  the  Gateway  Approach, 

Average  size  of  AUT  =  Number  of  Mobile  Users  /  Number  of  Gateways  (1) 

,  and  in  the  Satellite  Approach, 

Average  size  of  AUT  =  Number  of  Mobile  Users  /  Number  of  Satellites  (2) 

In  the  case  of  6  gateways  with  66  Iridium  satellites,  one  gateway  will  have  eleven  times 
larger  size  of  AUT  than  one  satellite.  This  implies  that  the  AUT  seek  time  of  gateway  is  not 
faster  than  that  of  satellite. 

4.5  Message  Traffic  Distribution  Over  the  Satellite 

Figures  10  and  11  show  the  average  number  of  call  setup  messages  at  each  orbit  during 

one  orbital  period  of  simulation  time  in  the  Satellite  Approach  and  Gateway  Approach, 
respectively.  In  the  Satellite  Approach,  the  average  number  of  messages  passed  through  one 
orbit  was  1953.67  messages  and  standard  deviation  was  131.85  messages,  whereas  in  the 
Gateway  Approach,  average  and  standard  deviation  was  2017.17  messages  and  285.2097 
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Orbit  vs.  Traffic  Passed  in  Satellite  Approach 


Orbit  Number 


—♦—SIM-1 
—■—SIM-2 
—A— SIM-3 
—•—SIM-4 


Figure  10  Message  Distribution  over  Orbits-Satellite  Approach 


Orbit  vs.  Traffic  Passed  in  Gateway  Approach 
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Figure  11  Message  Distribution  over  Orbits-Gateway  Approach 


40 


messages,  respectively.  This  result  implies  that  message  traffic  was  more  evenly  distributed  in 
the  Satellite  Approach  than  it  did  in  the  Gateway  Approach. 

In  the  Gateway  Approach ,  every  call  request  must  pass  through  the  gateway  for  the  user 
location  database  access  and  this  makes  the  satellite  near  by  gateways  always  busy.  Figure  12 
shows  that  the  orbit  tracks  and  gateway  positions  during  the  simulation  time.  Orbit-1,  Orbit- 
2  and  Orbit-5  are  passing  by  gateways  and  this  is  consistent  with  the  result  from  Figure  12. 

4.6  Summary 

In  this  Chapter,  the  simulation  result  of  two  ULD  algorithms  proposed  in  Chapter  3  was 
presented.  And  requirements  for  the  Satellite  Approach  was  examined.  The  Gateway  Approach 


Figure  12  Relationship  between  Orbits  and  Gateways 
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currently  has  no  limitation  in  implementing  the  system  while  the  Satellite  Approach  have 
minimal  limitations  in  the  memory  space  and  computational  ability  of  each  satellite. 
However,  the  Satellite  Approach  outperforms  than  the  Gateway  Approach  in  terms  of  fast  call 
setup  time  and  no  message  congestion. 

If  the  50Mbyte  of  memory  space  and  computational  ability  for  orbital  positioning 
calculation  are  feasible  in  current  satellite  manufacturing  technique,  the  Satellite  Approach  is 
the  most  likely  ULD  scheme  for  the  satellite  network  systems  . 
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5.  CONCLUSIONS 


5. 1  Overall  Performance  Comparison 

As  discussed  in  Chapter  4,  simulation  results  showed  that  the  Satellite  Approach  result  in 
average  of  0.022  seconds  faster  call  setup  time  and  average  of  2.91  less  Hop  Count  than  the 
Gateway  Approach.  In  case  of  the  Gateway  Approach,  12-gateway  simulation  showed  average  of 
0.012  seconds  faster  call  setup  time  than  6-gateway  simulation.  In  the  Satellite  Approach,  call 
setup  request  accesses  the  user  location  information  from  LHS,  while  in  the  Gateway 
Approach,  call  setup  request  accesses  the  user  location  information  from  Home  Gateway, 
which  requires  on  average  two  more  hops  to  travel  compare  to  the  Satellite  Approach. 
However,  this  can  be  possible  only  if  each  satellite  has  enough  memory  space  for  AUT  and 
VUT  and  also  have  to  handover  the  databases  to  next  satellite.  This  requirement  may 
increase  satellite  overhead  in  terms  of  computational  ability  and  memory  capacity  and  make 
it  harder  to  maintain  the  databases. 

Another  advantage  of  the  Satellite  Approach  is  that  message  traffics  are  more  evenly 
distributed  over  the  satellites  compare  to  the  Gateway  Approach,  which  can  prevent  message 
congestion  on  particular  satellites.  The  message  congestion  decreases  as  the  total  number  of 
gateways  increases,  and  this  can  cause  more  service  cost  to  subscribers. 

One  important  nature  of  the  Satellite  Approach  is  that  it  has  a  higher  survivability  than  the 
Gateway  Approach  in  case  of  system  loss.  For  instance,  if  we  lose  a  gateway  which  contains  all 
the  user  database  in  North  America,  the  whole  North  American  area  becomes  out  of  service 
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until  the  gateway  is  recovered.  In  case  of  the  Satellite  Approach ,  however,  only  a  footprint 
area  of  one  satellite  will  be  out  of  service  only  for  the  visible  time6  of  non-operating  satellite 
from  a  view  point  of  one  single  user.  Most  of  users  may  not  perceive  this  non-operation 
time,  while  some  of  heavily  dependent  users  feel  inconvenience  for  that  period  of  time. 

5.2  Future  Research 

This  thesis  is  based  on  the  assumption  that  all  the  AUT  and  VUT  are  maintained  by 
satellites,  and  the  user  location  information  tables  are  gracefully  passed  to  correct  satellites 
which  need  that  information.  This  assumption  can  be  solved  by  the  following  procedure. 

First,  we  have  to  analyze  the  satellite  network  topology  and  formulate  the  topology 
change.  By  doing  this,  we  can  calculate  the  exact  position  of  each  satellite  at  a  given  time. 

Second,  we  have  to  build  geopolitical  Iridium  Area  Code  database  in  order  to  map  a 
satellite  to  multiple  areas.  This  gives  satellites  area  information  which  will  have  to  be 
processed  and  updated.  Also,  each  satellite  can  pass  its  database  to  the  correct  satellite. 
Some  Iridium  Area  cannot  be  covered  by  one  satellite,  and  in  this  case,  all  the  satellites 
covering  one  particular  area  have  to  have  same  user  databases  for  that  area. 

One  more  case  not  discussed  in  this  thesis  is  that  of  the  call  setup  time  between  satellite 
network  and  terrestrial  network  like  PSTN  system.  If  we  try  to  communicate  with  terrestrial 
networks,  the  algorithms  suggested  in  this  paper  will  become  more  complex  and  cannot 


6  In  case  of  Iridium  satellite  network  system,  the  visibility  time  of  one  satellite  is  about  11.1  minutes. 
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work  without  gateways.  Thus,  we  need  to  develop  both  ways  to  maximize  the  network 
efficiency  and  flexibility. 

5.3  Conclusion 

In  this  thesis,  two  procedures  for  user  location  determination  were  introduced.  Delay 
performance  for  the  two  procedures  was  analyzed  using  network  simulation  program, 
BoNES  Designer  and  SatLab.  The  Satellite  Approach  used  satellites  for  database  storage, 
while  the  Gateway  Approach  used  gateways.  Gateways  are  also  needed  for  the  connection 
between  PSTN  and  satellite  network  and  for  this  reason,  many  countries  are  trying  to  build 
the  Iridium  gateway  in  their  area.  But,  the  number  of  gateways  planned  is  not  uncertain  yet, 
and  also  it  is  not  known  whether  all  the  gateways  will  be  used  for  user  location  database 
storage,  or  not.  If  current  satellite  manufacturing  technology  permits,  the  Satellite  Approach 
will  be  the  best  way  to  manage  user  location  databases.  Memory  requirements  and 
computational  ability  are  not  big  obstacles  at  this  time. 
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APPENDIX  A 


Detailed  Simulation  Definition 


A.1  Satellite  Approach 

Figure  13  is  the  top  level  block  diagram  of  Satellite  Approach.  The  six  temporal 
parameters  in  the  bottom  left  corner  are  used  to  set  the  starting  time  of  the  simulation. 
These  values  were  set  to  01/01/1997  10:30:00  in  this  simulation  and  can  be  set  to  any 
arbitrary  values. 


User  Location  Determination-Satellite  Approach  [  15-Oct-1997  15:52:27  ] 
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Figure  13  User  Location  Determination-Satellite  Approach 
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The  parameter  Area  Si%e  is  used  for  changing  the  size  of  geographical  area  that  has  its 
unique  Iridium  area  code.  In  this  simulation,  each  area  size  is  set  to  10,  15,  or  20  degree  of 
longitude  and  latitude  range,  which  implies  that  the  area  size  is  not  equally  divided  by  the 
absolute  value  of  each  area,  but  divided  by  earth  coordinate  value.  Thus,  absolute  size  value 
of  polar  area  is  smaller  than  that  of  equator  area,  and  this  method  was  used  because  of 
difficulties  in  building  a  geopolitical  area  database  at  this  point. 

The  parameter  System  Update  Delay  in  the  second  column  is  the  time  interval  between 
every  system  updating  procedures  (satellite  update  and  mobile  user  update).  In  this 
simulation,  the  value  is  set  to  60  seconds.  The  parameter  Mean  Inter-Pulse  Time  is  the  mean 
interval  time  value  used  in  Poison  traffic  generator.  This  value  is  set  to  1  second.  The 
parameter  Earth<->SAT  Data  Pate,  SAT<->SAT  Data  Pate  are  set  at  12.5  Mbps,  and  25Mbps, 
based  upon  the  data  rates  specified  in  the  Motorola  FCC  filing  for  Iridium  [FCC91].  The 
parameter  Antenna  mean  value  and  Antenna_angle  are  used  for  generating  Cost  Matrix,  which  is 
again  used  for  generating  a  routing  table,  and  set  to  78.5°  and  45°,  respectively. 

The  memory  variable  Number  of  Nodes  is  calculated  in  the  Initialize  System  block.  It  is  the 
sum  of  the  Number  of  MobileUsers,  Number  of  Satellites ,  and  Number  of  Earthstations  variables, 
which  are  passed  into  the  simulation  from  the  SatLab  program  based  on  the  constellation 
loaded. 

Distance  Table  Memory,  Visibility  Table  Memory,  and  Mobile  Eatitude  and  Eongitude  Table 
Memory  are  also  passed  into  the  simulation  by  SatLab  and  reflect  the  current  physical 
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locations  of  the  entities  in  the  constellation.  These  variables  are  used  by  the  routing  protocol 
to  calculate  touting  Table  Memory ,  which  is  a  matrix  of  next-hops  for  every  possible  source 
and  destination  in  the  network. 

Area  to  Satellite  Table(AST)y  Absent  User  Table(AUT),  and  Visiting  User  TablefVUT)  are  the 
tables  used  for  finding  user  locations  and  already  explained  in  Chapter  3.  Mobile  User  Position 
Table  is  a  profile  of  all  mobile  users,  which  is  used  for  keeping  track  of  the  position  of  all 
users.  Number  of  Traffic  Rejected  and  Passed  is  used  to  check  the  correctness  of  simulations. 

The  simulation  is  divided  by  two  main  parts,  POSITIONING  and 
COMMUNICATING.  POSITIONING  part  starts  first  because  the  internal  parameter 
Relative  Order  is  set  to  high  priority.  INITIALIZE  SYSTEM  block  is  executed  for  the  first 
time  and  Figure  14  shows  the  detail  block  diagram  of  INITIALIZE  SYSTEM  block. 

This  block  is  executed  only  once  during  the  whole  simulation  period.  It  receives  the 
number  of  satellites,  mobile  users,  and  earthstations  from  the  SatLab  program  and  calculate 
the  total  Number  of  Nodes.  Then,  it  initializes  all  the  memory  valuables  used  in  the  simulation. 
In  the  end,  it  creates  Mobile  User  Position  Table  using  Mobile  Longitude  I  Latitude  Table  Memory. 

After  initializing  the  system,  Update  Satellite  and  Update  MobileUser  block  is  executed 
without  any  delay,  and  these  two  blocks  are  executed  every  60  seconds  until  the  simulation 
finishes.  Figure  15  and  Figure  16  shows  the  detailed  block  diagram  of  Update  Satellite  and 
Update  MobileUser  block.  In  Update  Satellite  block,  the  system  first  receives  new  satellite 
location  data  from  the  SatLab  program  and  generates  a  new  routing  table,  which  is  saved  to 
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Figure  14  Initialize  System 

Routing  Table  Memory.  After  that,  this  block  calculates  the  closest  five  satellites  from  each 
Home  Area  and  save  the  results  to  new  Area  to  Satellite  Table(AST). 

In  Update  MobileUser  block  (Figure  16),  all  the  mobile  users’  new  location  coordinates  are 
sent  to  this  block  from  the  SatLab  program,  and  converted  to  area  code  in  which  each 
mobile  user  is  located.  If  the  area  code  of  the  new  position  is  different  from  that  of  the 
previous  position,  AUT  and  VUT  are  updated  with  a  new  area  code. 

Figure  17  shows  the  detailed  block  diagram  of  Update  AUT  block.  It  writes  the  new  area 
code  to  AUT  unless  the  new  area  code  is  same  as  the  mobile  user’s  Home  Area  code.  If  the 
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Figure  15  Update  Satellite 
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Figure  16  Update  Mobile  User 
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Update  AUT  [  1 5-Oct-1 997  1 5:51 :09  ] 
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Figure  17  Update  AUT 

mobile  user  comes  back  to  its  Home  Area,  the  current  area  field  will  be  set  to  0.  Figure  18 
shows  the  detailed  block  diagram  of  Update  VUT  block.  It  writes  the  mobile  user’s  Home 
Area  code  to  VUT  unless  the  mobile  user’s  Home  Area  code  is  same  as  the  visiting  area 
code. 

Once  the  first  iteration  of  updating  procedure  finishes,  the  COMMUNICATING  part 


Update  VUT  [  15-Oct-1997  15:52:01  ] 


Figure  18  Update  VUT 
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begins  execution.  Figure  19  shows  the  detailed  block  diagram  of  Traffic  Generator  block. 


T  raftic  G  enerator  [  1  S-Oct-1 997  1 5:50: 58  ] 


Figure  19  Traffic  Generator 

First  it  chooses  a  source  user  and  then,  it  chooses  a  destination  user  which  is  not  the 
same  as  a  source  user.  Figure  20  shows  the  detailed  block  diagram  of  Destination  User 
Generator  block.  Once  source  and  destination  User-Id  are  selected,  call  request  time  (Tnow), 
sequence  number,  and  packet  length  are  inserted  for  the  simulation  analysis  purpose. 


Figure  20  Destination  User  Generator 
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Then  call  setup  request  is  sent  to  Find  Start-SAT  and  End-SAT  block.  Figure  21  shows 
the  detailed  block  diagram  of  Find  Start-SAT  and  End-SAT  block.  In  this  block,  the  source 
user’s  call  request  is  connected  to  the  nearest  satellite  from  itself  (Start-SAT)  and  at  this 
point,  the  transmission  delay  and  propagation  delay  are  calculated  and  the  call  setup  request 
is  delayed  according  to  the  calculated  value. 


Figure  21  Find  Start-SAT  and  End-SAT 


Figure  22  is  the  detailed  block  diagram  of  Search  Nearest  SAT  block. 
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Figure  22  Search  Nearest  SAT 
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distance  between  the  source  user  and  all  the  satellites  visible  from  the  source  user.  The 
mobile  then  picks  the  nearest  satellite.  Figure  23  is  the  detailed  block  diagram  of  Delay  Start- 
SAT<->Source  Unk  block.  Propagation  delay  between  source  user  and  Start-SAT  can  be 
obtained  by  dividing  the  distance  between  two  nodes  by  the  speed  of  light.  Also, 
transmission  delay  can  be  calculated  by  dividing  the  number  of  bits  to  transmit  by  data  rate 
of  the  link.  As  soon  as  the  call  setup  request  arrives  at  the  Start-SAT,  it  looks  up  the  AST  in 


Figure  23  Delay  Start  SAT<-»  Source  Link 

the  satellite  memory  and  find  LHS  of  destination  user’  Home  Area  and  this  satellite  will  be 
the  End-SAT. 

Having  decided  the  End-SAT,  the  call  setup  request  is  routed  to  the  End-SAT  by 
propagating  signals  through  inter-satellite  links.  Figure  24  shows  the  detailed  block  diagram 
of  Route  from  SAT  to  SAT  block.  During  the  call  request  routing,  the  propagation  and 
transmission  delay  is  applied  and  total  delay  time  is  accumulated  in  each  step.  Figure  25 
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Figure  24  Route  from  SAT  to  SAT 

shows  the  detailed  block  diagram  of  Delay  SAT<->SAT  Link  block  and  this  is  exacdy  same  as 
Figure  23  except  the  Data  Rate  between  nodes. 


After  the  call  setup  request  arrives  at  the  End-SAT  of  destination  user,  it  can  find  the 
destination  user’s  current  location  from  the  AUT.  If  the  destination  user  is  not  in  his/her 
Home  Area,  the  call  setup  is  rerouted  to  the  new  End-SAT  which  is  the  nearest  satellite 


Figure  25  Delay  SAT<— >SAT  Link 
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Find  Destination  User  Location  [  15-Oct-1997  15:47:10  ) 


Destination  user  exists 
in  his  HomeArea. 


J5»  I  IN  [— 
>- — > 


Select 

destination 


W- 


V  V 
Read  Absent  i>| 
User  Table  1 

mn _ 


HU 


Execute 
Order  B| 


Search  AUT  before  paging  so  as  to  chech 
the  destination  user  being  absent  or  not. 


ip  Destination  user  doesn't 
— ist  in  his  HomeArea. 


Insert 

Insert 

Route  from 

— 

>  CurrentArea  > 

t>  End-SAT  > 

— DS 

>  SAT  to  > 

A 

A 

SAT 

New  End-SAT  > 
A _ A 


]-H>  i- 

Find  destination  user's 
Current  Area  and 
new  End-SAT 


DS  OUT{HomeArea) 
- > 


DS  OUT(VsitingArea) 
- 1> 


tP  SAT  <->  SAT  Data  Rate 


ITm  Number  ot  Nodes 
ITm  Number  of  Earthstations 
"I’M  Number  of  MobileUsers 
tM  Routing  Table  Memory 
ITm  Distance  Table  Memory 
ITm  Absent  User  Table  (AUT) 

ITm  Area  to  Satellite  Table(AST) 
ITm  Number  of  Traffic  Passed 


Figure  26  Find  Destination  User  Location 


from  destination  user’s  Current  Area.  Figure  26  shows  the  detailed  block  diagram  of  Find 
Destination  User  Location  block. 


Finally,  the  call  setup  request  signal  arrives  at  the  satellite  which  is  indicated  in  the  AUT 
of  a  destination  user.  Figure  27  shows  the  detailed  block  diagram  of  Page  from  End-SAT.  In 
this  step,  if  the  destination  user  is  in  his  or  her  Home  Area,  he  or  she  pages  a  call  signal.  If 
the  destination  user  is  in  visiting  area,  however,  he  or  she  tries  to  access  the  VUT  in  End- 
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Figure  27  Page  from  End-SAT 
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SAT  and  then  pages  a  call  signal  only  if  the  destination  User-ID  exist  in  that  table.  If  the 
destination  user  exists  under  the  footprint  area  of  End-SAT,  he  or  she  replies,  but  if  the 
destination  user  does  not  exist,  the  call  setup  request  is  rerouted  to  next  priority  End-SAT 
according  to  AST.  This  rerouting  procedure  is  repeated  until  the  destination  user  is  found 
or  it  searches  all  the  End-SAT  in  AST. 


Figure  28  and  29  shows  the  detailed  block  diagram  of  Search  Destination  User  from  End- 
SAT  block  and  Change  End-SAT  to  Next  Priority  SAT,  respectively.  In  Figure  28,  the 
destination  user’s  existence  is  decided  by  checking  the  visibility  between  the  End-SAT  and 
destination  user.  The  simulation  assumes  that  destination  user  replies  without  any  delay  only 
if  he  or  she  is  visible  from  End-SAT.  In  Figure  29,  the  End-SAT  is  replaced  by  next  priority 
satellite  indicated  in  AST  and  the  call  setup  request  is  routed  to  the  new  End-SAT.  If  the 
call  setup  request  signal  cannot  find  the  destination  user  after  searching  the  lowest  priority 
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Figure  28  Search  Destination 
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Figure  29  Change  End-SAT  to  Next  Priority  SAT 

End-AT  in  AST,  the  call  setup  request  is  declined  and  stop  searching  destination  user. 
Once  the  call  setup  request  find  the  destination  user,  it  calculates  the  round  trip  delay 
between  End-SAT  and  destination  user  and  is  delayed  in  Delay  End-SAT<r^Destination  Link 
block  (Fig30). 


After  the  call  setup  request  succeeds  in  finding  destination  user,  call  setup  success  signal 
is  rerouted  to  the  original  Start-SAT  to  finish  the  call  setup  process.  Figure  31  shows  the 
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Figure  31  Reroute  from  SAT  to  SAT 

detailed  block  diagram  of  Reroute  from  SAT  to  SAT  block.  After  the  Start-SAT  receives  the 
call  setup  success  signal,  it  sends  the  signal  to  the  source  user  and  finally,  the  call  setup 
request  is  established.  In  Figure  32,  the  final  delay  time  is  calculated  and  the  result  is  stored 
to  delay  field  in  the  call  setup  request  data  structure. 

A.  2  Gateway  Approach 

Figure  33  shows  the  top  level  block  diagram  of  the  Gateway  Approach.  In  this  approach, 
one  more  parameter  and  one  more  memory  variable  are  used  than  the  Satellite  Approach.  The 
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Figure  32  Connection  Established 
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User  Location  Determination-Gateway  Approach  [  15-Oct-1997  15:52:14  ] 
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Figure  33  User  Location  Determination-Gateway  Approach 

parameter  AreatoGateway  Table  Tile  is  a  mapping  file  which  maps  each  area  to  its  Home 
Gateway.  Using  this  external  mapping  file,  the  simulation  generates  a  memory  variable  Area 
to  Satellite  Table(AGT). 

The  other  parameters  and  memory  variables  used  in  the  Gateway  Approach  are  exactly  the 
same  as  those  of  the  Satellite  Approach.  Each  block  function  in  the  Gateway  Approach  is  same 
as  in  the  Satellite  Approach  except  4  blocks  ( Jnitiali^eSystem[GW]  block,  Find  Start-SAT  and 
End-SAT  [GW]  block.  Find  Destination  User  Location  [GW]  block,  and  Delay  SAT—tCAV  block). 
In  this  section,  only  these  four  block  functions  are  covered. 
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Initialize  System  [GW]  [  15-Oct-1997  15:49:28  ] 
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Figure  34  Initialize  System[GW] 

Figure  34  shows  the  detailed  block  diagram  of  Initialise  System  [GW].  In  this  block, 
generating  memory  variable  Area  to  Gateway  Table  (A  GT)  is  added  to  Initialise  System  block 
(Figure  14).  Using  this  memory  variable,  all  the  area  code  can  recognize  the  position  of  their 
Home  Gateway. 

Figure  35  shows  the  detailed  block  diagram  of  Find  Start-SAT  and  End-SAT[GW].  First 
the  call  setup  request  signal  searches  the  nearest  satellite  from  source  user  like  in  the  Satellite 
Approach.  However,  the  End-SAT  is  selected  among  the  nearest  satellites  from  destination 
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Figure  35  Find  Start-SAT  and  End-SAT[GW] 

user’s  Home  Gateway  instead  of  his  or  her  Home  Area.  This  implies  that  the  call  setup 
request  signal  is  not  routed  to  the  destination  user’s  LHS,  but  routed  to  his  or  her  Home 
Gateway. 

Once  the  call  setup  request  signal  decide  the  End-SAT,  it  is  routed  to  the  End-SAT  and 
tries  to  communicate  with  the  gateway  located  under  the  End-SAT.  Figure  36  shows  the 
detailed  block  diagram  of  Find  Destination  User  Location  [GW],  Before  the  call  setup  request 
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Figure  36  Find  Destination  User  LocationfGW] 
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arrives  at  destination  user’s  Home  Gateway,  additional  delay  required  to  communicate  with 
gateway  station  is  applied  (Figure  37). 


Figure  37  Delay  SAT— >GW  Link 

After  the  call  setup  request  signal  arrives  at  the  gateway,  it  finds  the  destination  user’s 
current  location  information  from  the  AUT  and  decides  on  a  new  End-SAT  with  the 
current  location  data.  The  call  setup  request  signal  is  now  heading  to  the  new  End-SAT  and 
routed  until  it  arrives  at  new  End-SAT. 

After  the  call  setup  request  signal  arrives  at  the  new  End-SAT  that  is  orbiting  over 
destination  user’s  area,  all  the  rest  procedure  is  executed  exacdy  same  as  Satellite  Approach. 

A..3  Data  Structure  of  Call  Setup  Request  Packet 

The  data  structure  of  call  setup  request  packet  used  in  simulations  is  presented  in  Table 
5. 
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Table  5  SatCom-Traffic  Data  Structure 


Field  Name 

Data  Type 

Data  Range 

Defaul 

source 

INTEGER 

[0,  +Infinity) 

destination 

INTEGER 

[0,  +Infinity) 

packet  length 

INTEGER 

[0,  +Infinity) 

sequence  number 

INTEGER 

[0,  +  Infinity) 

Current  Area 

INTEGER 

[0,  +Infinity) 

Start-SAT 

INTEGER 

[0,  +Infinity) 

Current-SAT 

INTEGER 

[0,  +Infinity) 

Next-SAT 

INTEGER 

[0,  +Infinity) 

End-SAT 

INTEGER 

[0,  +Infinity) 

End-SAT  Priority 

INTEGER 

[1,5] 

i 

Time  Created 

REAL 

[0,  +Infinity) 

Time  Connected 

REAL 

[0,  +Infinity) 

Delta  Delay 

REAL 

[0,  + Infinity) 

0.0 

Delay 

REAL 

[0,  +Infinity) 

0.0 

HopCount 

INTEGER 

[0,  +Infinity) 

0 
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